|
The RTSS environment has no process priority classes, so the threads of all RTSS processes compete for a CPU using the thread priority only. Each process has a priority-based ready queue, which guarantees that threads execute in priority order and in "first in, first out" order within any single priority. If a time quantum is set to 0, the thread will run to completion. If the time quantum is set to any other value, the thread will run for the specified time and then give up the CPU to another thread with the same priority
RTX scheduling allows an RTSS thread to execute at any one of 128 real-time priorities. A Win32 program that links in RTX calls will begin execution using the normal Win32 priority class (THREAD_PRIORITY_NORMAL), but can gain a real-time priority class after calling any real-time priority function. To allow GUI-based Win32 threads to be scheduled before other Win32 threads, call SetPriorityClass. To allow the GUI-based thread to be scheduled on an equal basis with Windows real-time threads, call a real-time priority function, such as RtGetThreadPriority or RtSetThreadPriority, to give the program a real-time priority class.
For more information about thread promotion and demotion, see Mutex Object Overview.
The RTSS to Win32 Thread Priority Mapping table below shows how RTSS symbolic priority names translate to requests for a particular Windows priority when RtSetThreadPriority is called by a Win32 program.
RTSS Symbolic Priority Name | RTSS Value | Windows Symbolic Priority Name for Real-Time Priority Class | Win32 Value |
---|---|---|---|
RT_PRIORITY_MIN | 0 | THREAD_PRIORITY_IDLE | 16 |
RT_PRIORITY_MIN + 1 | 1 | THREAD_PRIORITY_LOWEST | 22 |
RT_PRIORITY_MIN + 2 | 2 | THREAD_PRIORITY_BELOW_NORMAL | 23 |
RT_PRIORITY_MIN + 3 | 3 | THREAD_PRIORITY_NORMAL | 24 |
RT_PRIORITY_MIN + 4 | 4 | THREAD_PRIORITY_ABOVE_NORMAL | 25 |
RT_PRIORITY_MIN + 5...+ 126 | 5...126 | THREAD_PRIORITY_HIGHEST | 26 |
RT_PRIORITY_MAX | 127 | THREAD_PRIORITY_TIME_CRITICAL | 31 |
The table shows, for example, that RtSetThreadPriority(Thread, RT_PRIORITY_MIN+1) will result in a call to SetThreadPriority(Thread, THREAD_PRIORITY_LOWEST) by the Win32 version of the RTX interfaces.
Any value from RT_PRIORITY_MIN+5 to RT_PRIORITY_MIN+126 will set the thread at THREAD_PRIORITY_HIGHEST and RT_PRIORITY_MAX will result in THREAD_PRIORITY_TIME_CRITICAL priority. These mappings are fixed and designed to preserve relative ordering among thread priorities.
If a Win32 program calls RtGetThreadPriority, the real-time priority specified in the call to RtSetThreadPriority returns. There are some restrictions, however. The most likely source of confusion is when calls to RtSetThreadPriority and SetThreadPriority are mixed. The library may not always understand the RTSS priority when a duplicated thread handle is used, and it will return RT_PRIORITY_MIN+5 instead of RT_PRIORITY_MIN+6 through RT_PRIORITY_MIN+126. Threads that set and get their own RTSS priorities (such as specifying the thread with GetCurrentThread), will always get the RTSS priority that was set.
Win32 programs should use the Rt priority calls for the Win32 thread to claim other than the lowest RTSS scheduling priority when waiting on an RTSS synchronization object. For instance, a Win32 thread with an RTSS priority of RT_PRIORITY_MAX will own a mutex before an RTSS thread waiting for the same mutex with a priority less than RT_PRIORITY_MAX.
The Win32 to RTSS Thread Priority Mapping table below shows what callers of the Win32 "set" and "get" thread priority calls should expect in the RTSS environment. This table describes the inverse of the mapping shown in Table 1.
Windows Symbolic Priority Name for Real-Time Priority Class | Value | RTSS Symbolic Priority Name | Value |
---|---|---|---|
THREAD_PRIORITY_MIN | 16 | THREAD_PRIORITY_IDLE | 0 |
THREAD_PRIORITY_MIN + 1 | 22 | THREAD_PRIORITY_LOWEST | 1 |
THREAD_PRIORITY_MIN + 2 | 23 | THREAD_PRIORITY_BELOW_NORMAL | 2 |
THREAD_PRIORITY_MIN + 3 | 24 | THREAD_PRIORITY_NORMAL | 3 |
THREAD_PRIORITY_MIN + 4 | 25 | THREAD_PRIORITY_ABOVE_NORMAL | 4 |
THREAD_PRIORITY_MIN + 5...+ 126 | 26 | THREAD_PRIORITY_HIGHEST | 5 |
THREAD_PRIORITY_MAX | 31 | THREAD_PRIORITY_TIME_CRITICAL | 127 |
There are no additional priorities between THREAD_PRIORITY_IDLE and THREAD_PRIORITY_HIGHEST. If you need finer grain priorities, you should use the RTSS priority spectrum instead. Just as in Win32, this value specifies a thread priority that is higher than all other priorities.
A Win32 RTX-linked program starts execution in the normal priority class, as soon as the program calls RtGetThreadPriority, RtSetThreadPriority, or any other real-time priority function the programs priority class becomes the real-time priority class.
This is the desired behavior for most applications because it gives the process the best possible real-time performance. This does, however, cause problems when the Win32 threads have GUI components. When a thread in the REALTIME_PRIORITY_CLASS interacts with the GUI side of Windows, slowdowns and lock-ups occur. You can avoid this problem when writing a Win32 application that has a GUI component (and links to rtapi_win32.lib), by making sure that your program first makes this call:
SetPriorityClass( GetCurrentProcess(), NORMAL_PRIORITY_CLASS)
NOTE: If you do set your application's priority as described above, the application's GUI may not refresh its data if it is not the topmost window.